…#2530)

Summary
Fixes a regression where the context usage meter disappears after
switching back to a workspace that compacted while backgrounded.

Background
Recent boundary-windowed replay behavior only scans the active
compaction epoch for context usage. When the newest message in that
epoch is the compaction boundary summary and that summary has no
`contextUsage`, the UI shows no usage until later tool/model events
arrive.

Implementation
- `CompactionHandler` now sanitizes compaction stream-end metadata by
stripping stale provider metadata while attaching a post-compaction
context estimate (`systemMessageTokens + summary output tokens`) as
`contextUsage` when available.
- `WorkspaceStore` now checks compaction boundary messages for
`contextUsage` before stopping its backwards epoch scan.
- Added targeted regression tests in both `compactionHandler.test.ts`
and `WorkspaceStore.test.ts`.

Risks
Low-to-moderate. The behavior change is scoped to post-compaction
metadata and usage display fallback. Tests cover both estimate presence
and omission paths.

---

<details>
<summary>📋 Implementation Plan</summary>

# Fix: Context Usage Meter Disappears on Workspace Switch

## Context / Why

After the boundary-windowed chat loading change (PR #2493) and
auto-compaction backend move (PR #2469), the context usage meter
disappears when switching between workspaces. The user must wait for one
or two agent tool calls before it reappears.

**Root cause:** When idle compaction fires while a workspace is
backgrounded, the compaction summary intentionally strips `contextUsage`
(to avoid displaying stale pre-compaction values). On switch-back, the
frontend replays only the current epoch (post-boundary). If the only
message in that epoch is the compaction summary (which has no
`contextUsage`), the backward scan returns `undefined` → meter shows
empty.

## Evidence

| File | What it tells us |
|---|---|
| `src/node/services/compactionHandler.ts:515-535` |
`sanitizeCompactionStreamEndEvent` strips `contextUsage`,
`providerMetadata`, `contextProviderMetadata` from the compaction
stream-end event |
| `src/node/services/compactionHandler.ts:688-706` | Compaction summary
message has `systemMessageTokens` and `usage` (with `outputTokens` =
summary size) but no `contextUsage` |
| `src/browser/stores/WorkspaceStore.ts:1690-1706` | Backward scan
`break`s at `isDurableCompactionBoundaryMarker` **without** checking the
boundary message for `contextUsage` |
| `src/node/services/agentSession.ts:2323-2360` | Backend
`seedUsageStateFromHistory` scans the boundary epoch (including boundary
msg) for `contextUsage` — currently finds nothing because boundary has
none |
| `src/common/utils/messages/compactionBoundary.ts:11-13` |
`hasDurableCompactedMarker` accepts `true \| "user" \| "idle"` |
| `src/node/services/compactionMonitor.ts` | Auto-compaction threshold
is 70% (`DEFAULT_AUTO_COMPACTION_THRESHOLD = 0.7`), triggered by
backend's own `lastUsageState` — completely independent of frontend
display |

## Approach: Post-Compaction Context Estimate on Boundary Messages

Instead of stripping `contextUsage` entirely, **replace** it with a
computed post-compaction estimate representing the approximate context
window size *after* compaction (system prompt + summary).

### Why this is safe from compaction loops

The post-compaction estimate is inherently small:

```
estimate = systemMessageTokens + compactionSummary.outputTokens
         ≈ 5–15% of context window
```

- Auto-compaction triggers at **70%** — the estimate is far below this.
- Backend `seedUsageStateFromHistory` would find this small value on
restart → no re-compaction.
- The compaction trigger (`CompactionMonitor`) uses the backend's
in-memory `lastUsageState` from actual provider responses, **not** the
frontend display. Even if the estimate were somehow wrong, it cannot
cause a backend loop.

### What the user sees

| State | Meter |
|---|---|
| Before compaction | 70% (real) |
| After compaction, before next response | ~10% (estimate — system
prompt + summary) |
| After next agent response | Real value from new `contextUsage` |

## Implementation Details (~20 net LoC)

### 1. Backend: Compute estimate in `CompactionHandler` 

**File:** `src/node/services/compactionHandler.ts`

In `sanitizeCompactionStreamEndEvent`, instead of stripping
`contextUsage`, replace it with a post-compaction estimate:

```typescript
private sanitizeCompactionStreamEndEvent(event: StreamEndEvent): StreamEndEvent {
  const { providerMetadata, contextProviderMetadata, contextUsage, timestamp, ...cleanMetadata } =
    event.metadata;

  // Compute a post-compaction context estimate: system prompt + summary tokens.
  // This gives the frontend a directionally-correct "near empty" reading while
  // preventing stale pre-compaction values from inflating the meter.
  const postCompactionContextEstimate = this.computePostCompactionContextEstimate(
    cleanMetadata.systemMessageTokens,
    cleanMetadata.usage,
  );

  const sanitizedEvent: StreamEndEvent = {
    ...event,
    metadata: {
      ...cleanMetadata,
      ...(postCompactionContextEstimate && { contextUsage: postCompactionContextEstimate }),
    },
  };

  assert(
    sanitizedEvent.metadata.providerMetadata === undefined &&
      sanitizedEvent.metadata.contextProviderMetadata === undefined,
    "Compaction stream-end event must not carry stale provider metadata",
  );

  return sanitizedEvent;
}

/**
 * Approximate context window size after compaction: system prompt + summary.
 * Returns undefined if inputs are missing (graceful fallback to no-data).
 */
private computePostCompactionContextEstimate(
  systemMessageTokens: number | undefined,
  usage: LanguageModelV2Usage | undefined,
): LanguageModelV2Usage | undefined {
  const summaryTokens = usage?.outputTokens;
  if (summaryTokens == null || summaryTokens <= 0) return undefined;

  const systemTokens = systemMessageTokens ?? 0;
  const estimatedInputTokens = systemTokens + summaryTokens;

  return {
    inputTokens: estimatedInputTokens,
    outputTokens: 0,
  };
}
```

### 2. Frontend: Read boundary's `contextUsage` before breaking

**File:** `src/browser/stores/WorkspaceStore.ts`

Modify the backward scan (~line 1693) to check the boundary message for
`contextUsage` before breaking:

```typescript
const lastContextUsage = (() => {
  for (let i = messages.length - 1; i >= 0; i--) {
    const msg = messages[i];
    if (isDurableCompactionBoundaryMarker(msg)) {
      // Boundary may carry a post-compaction context estimate.
      // Check before breaking so the meter shows "near-empty" instead of nothing.
      const rawUsage = msg.metadata?.contextUsage;
      if (rawUsage && msg.role === "assistant") {
        const msgModel = msg.metadata?.model ?? model ?? "unknown";
        return createDisplayUsage(rawUsage, msgModel, undefined);
      }
      break;
    }
    if (msg.role === "assistant") {
      if (msg.metadata?.compacted) continue;
      // ... existing contextUsage extraction (unchanged)
    }
  }
  return undefined;
})();
```

### 3. Update assertion message

**File:** `src/node/services/compactionHandler.ts`

The existing assertion (line 527-531) checks `contextUsage ===
undefined`. Update it to allow the new estimate:

```typescript
assert(
  sanitizedEvent.metadata.providerMetadata === undefined &&
    sanitizedEvent.metadata.contextProviderMetadata === undefined,
  "Compaction stream-end event must not carry stale provider metadata",
);
```

(Remove the `contextUsage === undefined` check from the assertion.)

### 4. Tests

- **CompactionHandler tests:** Verify `sanitizeCompactionStreamEndEvent`
produces a post-compaction estimate (not the pre-compaction value) when
`systemMessageTokens` and `usage.outputTokens` are available, and
produces `undefined` when they're missing.
- **WorkspaceStore tests (or unit test for the scan logic):** Verify the
backward scan reads `contextUsage` from a boundary message when no newer
messages have it.
- **Integration/manual:** Switch between workspaces after idle
compaction → meter should show a small value instead of disappearing.

<details>
<summary>Alternatives considered</summary>

### Alt A: Store `lastContextUsage` in `session-usage.json`

Persist `lastContextUsage` to disk alongside existing session usage
data. Clear it on compaction.

- **Pro:** Survives restarts independently of message history.
- **Con:** After compaction, still shows empty (cleared). Adds new
persistence field + service changes.
- **Con:** More moving parts, touches both `SessionUsageService` and
`WorkspaceStore`.

### Alt B: Include `lastContextUsage` in the `caughtUp` IPC payload

Backend sends its in-memory `lastUsageState` in the `caughtUp` event.

- **Pro:** Always authoritative, no new persistence.
- **Con:** `lastUsageState` may be stale/undefined after compaction.
Requires IPC schema change. Frontend still needs fallback logic.

### Alt C: Frontend caches value before clearing aggregator

Before `resetChatStateForReplay` clears the aggregator, snapshot the
current `lastContextUsage` and use as fallback.

- **Pro:** Frontend-only change.
- **Con:** Shows stale pre-compaction value (70%) then drops to real
value — worse UX. Doesn't survive restart.

### Alt D: Don't strip `contextUsage` from compaction boundary (carry
forward original)

- **Con:** This is the infinite loop scenario the user warned about.
Backend `seedUsageStateFromHistory` would read the inflated
pre-compaction value, seed `lastUsageState` to 70%, and
`checkBeforeSend` would immediately trigger another compaction.
</details>

</details>

---

_Generated with `mux` • Model: `openai:gpt-5.3-codex` • Thinking:
`xhigh` • Cost: `$8.29`_

<!-- mux-attribution: model=openai:gpt-5.3-codex thinking=xhigh
costs=8.29 -->

…t totals (#2546)

## Summary

Fixes stale workspace cost totals when switching between workspaces. The
frontend fetched persisted session usage (`session-usage.json`) only
once during workspace registration (`addWorkspace`), so cost rollups
arriving while a workspace was inactive (e.g., sub-agent deletions) were
never picked up until a hard refresh.

## Background

PR #2493 introduced boundary-windowed chat loading, where only the
active workspace receives a full `onChat` subscription. Non-active
workspaces use metadata-only activity feeds. This means
`session-usage-delta` events — which carry sub-agent cost rollups — only
reach the currently active workspace.

Since `getSessionUsage()` was only called once during `addWorkspace()`,
switching back to a workspace that received rollups while inactive would
show stale (lower) cost totals. Users reported workspaces dropping from
~$20 to <$5 until `Ctrl+Shift+R` forced a full reload.

## Implementation

- Extracted the inline `getSessionUsage` fetch + repricing logic from
`addWorkspace()` into a shared `refreshSessionUsage()` private method.
- Added a per-workspace request version guard so slower/older fetch
responses cannot overwrite fresher state during rapid workspace
switches.
- `setActiveWorkspaceId()` now calls `refreshSessionUsage()` for the
newly active workspace, re-hydrating any cost data that arrived while it
was inactive.
- Cleanup: `removeWorkspace()` clears the request-version tracking for
deleted workspaces.

## Validation

- New regression tests:
- Verifies activation triggers a fresh `getSessionUsage` fetch and
hydrates `sessionTotal`
- Verifies stale in-flight responses are dropped when a newer refresh
supersedes them
- All existing `WorkspaceStore.test.ts` tests pass
- `make typecheck` passes

---

_Generated with `mux` • Model: `anthropic:claude-opus-4-6` • Thinking:
`xhigh`_

<!-- mux-attribution: model=anthropic:claude-opus-4-6 thinking=xhigh
costs=9.21 -->